The goal of this work is to upgrade and migrate JIRA 3.12.1 from oceana.mbari.org to 6.X on bugs.mbari.org

Documentation

1. Atlassian docs:
   1. Top level upgrade doc: https://confluence.atlassian.com/display/JIRA/Upgrading+JIRA
   2. Skipping Major versions: https://confluence.atlassian.com/display/JIRA/Skipping+Major+Versions+When+Upgrading+JIRA
   3. Migration from 3.12.1 -> 4.4: https://confluence.atlassian.com/display/JIRA044/Migrating+JIRA+to+Another+Server
   4. The JIRA configuration tool: https://confluence.atlassian.com/display/JIRA044/Using+the+JIRA+Configuration+Tool

Steps

1. Create new VM named bugs.mbari.org in the DMZ
2. Have Neil create database Jira_Temp on solstice2.shore.mbari.org
3. Have Neil create database Jira on solstice2.shore.mbari.org
4. Have Pat install Java 7 on bugs.shore.mbari.org
5. Have Pete plumb holes through firewall so processes on bugs.mbari.org can get to Solstice2
6. Have Pat create DB_Collaboration account on bugs so it can run JIRA under that account and it can connect to solstice2 using that NT Domain account.
7. Upgrade license on Atlassian site
8. Log into bugs.shore.mbari.org
9. Download 3.13.5 standalone Linux 64 bit tar.gz
10. Unzip and untar the file to /opt
11. Download 4.4.5 standalone Linux 64 bit tar.gz
12. Unzip and untar the file to /opt
13. Download 5.2.11 standalone Linux 64 bit tar.gz (not sure this version is necessary, but at least I have it)
14. Unzip and untar the file to /opt
15. Download latest JIRA (6.4.7 as of this writing).
16. Unzip and untar it to /opt
17. Performed Test Upgrade
    1. In order to export the current stuff in JIRA, I had to shut off access so people could not change the data while I was backing it up.
    2. I ssh'd to oceana.mbari.org as root and edited the /opt/jira/conf/server.xml file and commented out the Connector section that had the port of 8010 to shut it off from the normal serving route.
    3. I uncommented the 8082 port connector and the 8443 port connector so that I could still get to the server.
    4. I stopped and started the JIRA server and in the log file I got a "keystore was tampered with..." which is not surprising.
    5. I could then browser over to http://oceana.mbari.org:8082/jira
    6. Then through the Administration console, I did an XML backup
    7. I then created a tar of all the attachments in the /data/jira_3_12/attachments directory
    8. I moved both the XML and tar files to the /root/jira-upgrade directory
    9. I then reversed the changes to the server.xml file and shut down JIRA
    10. I left it down during the next steps in case it went so well, I could just point people to the new server (yeah, right).
    11. I then browsed to the crowd server on oceana and add a new application using:
        1. URL: http://bugs.mbari.org/jira3135
        2. IP: 134.89.2.29
        3. Name: JIRA3135
        4. Password: (ask Kevin)
    12. On bugs, I made a copy of the JIRA 3.13.5 download in the /opt directory and unzipped and untarred it.
    13. In order to configure the crowd connection I did the following:
        1. I scp'd the /opt/crowd/client/crowd-integration-client-1.6.jar file from oceana to the /opt/atlassian-jira-standalone-3.13.5/atlassian-jira/WEB-INF/lib directory
        2. I removed the existing 1.6.1 crowd client jar from the /opt/atlassian-jira-standalone-3.13.5/atlassian-jira/WEB-INF/lib directory
        3. I scp'd the /opt/crowd/client/conf/crowd.properties file from oceana to the /opt/atlassian-jira-standalone-3.13.5/atlassian-jira/WEB-INF/classes directory
        4. I scp'd the /opt/crowd/client/conf/crowd-ehcache.xml file from oceana to the /opt/atlassian-jira-standalone-3.13.5/atlassian-jira/WEB-INF/classes directory
        5. I edited the crowd.properties file on bugs to look like:

           application.name                        JIRA3135
           application.password                    (ask Kevin)
           application.login.url                   http://oceana.mbari.org:8095/crowd/console/
           
           crowd.server.url                        http://oceana.mbari.org:8095/crowd/services/
           
           session.isauthenticated                 session.isauthenticated
           session.tokenkey                        session.tokenkey
           session.validationinterval              0
           session.lastvalidation                  session.lastvalidation
           

        6. I edited the /opt/atlassian-jira-standalone-3.13.5/atlassian-jira/WEB-INF/classes/osuser.xml file to comment out the current authentication mechanism and then uncomment the crowd one.
    14. I then edited the /opt/atlassian-jira-standalone-3.13.5/conf/server/xml file and configured the database connection to the Jira_Temp database on Solstice2. I looked like this:

                <Context path="" docBase="${catalina.home}/atlassian-jira" reloadable="false">
                  <Resource name="jdbc/JiraDS" auth="Container" type="javax.sql.DataSource"
                    username="DB_Collaboration"
                    password="(ask Kevin)"
                    driverClassName="net.sourceforge.jtds.jdbc.Driver"
                    url="jdbc:jtds:sqlserver://solstice2.shore.mbari.org:1433/Jira_Temp;domain=SHORE"
                    maxActive="20" />
        

    15. Edit the /opt/atlassian/jira-standalone-3.13.5/atlassian-jira/WEB-INF/classes/entityengine.xml and changed it from 'hsql' to 'mssql' and delete the line with "PUBLIC" in it per the instructions in the comments in that file.
    16. I edited the /etc/httpd/conf/httpd.conf file and created a proxy pass at the bottom of the file to point a normal URL to the default port 8080 for JIRA:

        # Proxy Pass for JIRA
        <Location /jira3135>
                ProxyPass http://bugs.mbari.org:8080
                ProxyPassReverse http://bugs.mbari.org:8080
        </Location>
        

    17. I restarted Apache
    18. I scp'd the jtds driver from oceana to the /opt/atlassian-jira-standalone-3.13.5/common/lib directory (you could down from the internet)
    19. I then went to the /opt/atlassian-jira-standalone-3.13.5/ directory and ran './bin/startup.sh'. From the log file, I could tell things were hanging. After some troubleshooting I am wondering if the local firewall is preventing the application to get access to the database on solstice2. I can telnet to port 1433, but I can't browse to the base http://bugs.mbari.org from anywhere but the local web browser. I have submitted a ticket.
    20. I restarted the old JIRA with my hopes dashed .
    21. Pat disabled the firewall on bugs.mbari.org but it still hung trying to connect to solstice2.shore.mbari.org. That is really, really perplexing. Neil mentioned that solstice2 is using Kerberos and solstice is not. Checking with the JTDS docs, version 1.3.1 of the driver added kerberos support, so I downloaded that driver and added the 'userKerberos=true' property to the URL in the server.xml file and restarted. Got an error about no credentials, so added user and password properties to the URL. Nope, no luck. Never did figure this one out, but I had Pat pull the VM inside the firewall and after some thrash it worked. Well, it sort of worked ... sigh. It turns out I had downloaded the standard version instead of the enterprise version. I need to redo this work ... grrr.
    22. I deleted all the tables in the Jira_Temp database and removed the /data/jira3135/indexes directory (and recreated).
    23. I downloaded the enterprise version of the 3.13.5 server. I made a copy in the /opt directory and unzipped and untarred the file.
    24. I went back to crowd and edited the application to change the properties to:
        1. URL: http://bugs.shore.mbari.org:8080
        2. IP: 134.89.12.31
        3. Name: jira3135
        4. Password: (ask Kevin)
    25. I then repeated the steps above to get the server up and running with the following differences:
        1. The server name is now bugs.shore.mbari.org
        2. The paths given above are a little different in that they no longer say "standard" but say "enterprise"
        3. I deleted the proxy pass as it seemed to have issues before and this is only temporary anyway.
    26. I then browsed to http://bugs.shore.mbari.org:8080
    27. It took me to the start up page and at the top was the option to 'import your existing data'. Seemed too good not to try. I clicked on the link. It asked me for the backup file location and the location where the indexes would be stored.
    28. I copied the XML zip file and the attachments tar file to the /data/original directory.
    29. I created the /data/jira3135/indexes and used those directories ... it fired off the import and I waited.
    30. I tailed the log file to watch the import. Holy crap, it worked!!! I could log in and everything! I copied the results from the log file here for posterity sake:

        2015-07-22 20:55:45,156 http-8080-Processor22 INFO [jira.action.admin.DataImport] Running data import
        2015-07-22 20:55:45,179 http-8080-Processor22 INFO [jira.action.admin.DataImport] Importing data..
        2015-07-22 20:55:45,186 http-8080-Processor22 INFO [jira.action.admin.DataImport] Start parsing XML with SAX Parser
        2015-07-22 20:56:24,211 http-8080-Processor22 INFO [jira.action.admin.DataImport] XML successfully parsed
        2015-07-22 20:56:24,211 http-8080-Processor22 INFO [jira.action.admin.DataImport] Removing all entries from the database.
        2015-07-22 20:56:24,593 http-8080-Processor22 INFO [jira.action.admin.DataImport] All entries removed.
        2015-07-22 20:56:24,594 http-8080-Processor22 INFO [jira.action.admin.DataImport] Started storing 410414 Generic Values
        2015-07-22 21:01:51,967 http-8080-Processor22 INFO [jira.action.admin.DataImport] Finished storing Generic Values
        2015-07-22 21:01:52,329 http-8080-Processor22 WARN [atlassian.jira.util.LuceneUtils] Directory /data/jira3135/indexes/entities/searchrequest does not exist - perhaps it was deleted?  Creating..
        2015-07-22 21:01:52,361 http-8080-Processor22 WARN [atlassian.jira.util.LuceneUtils] Directory /data/jira3135/indexes/entities/portalpage does not exist - perhaps it was deleted?  Creating..
        2015-07-22 21:01:54,683 http-8080-Processor22 INFO [jira.plugin.profile.DefaultUserFormatMapper] Mapping type 'profileLink' to module 'jira.user.format:profile-link-user-format'.
        2015-07-22 21:01:54,724 http-8080-Processor22 INFO [jira.plugin.profile.DefaultUserFormatMapper] Mapping type 'fullName' to module 'jira.user.format:full-name-user-format'.
        2015-07-22 21:01:54,773 http-8080-Processor22 INFO [jira.plugin.profile.DefaultUserFormatMapper] Mapping type 'profileLinkSearcher' to module 'jira.user.format:profile-link-searcher-user-format'.
        2015-07-22 21:01:54,784 http-8080-Processor22 INFO [jira.plugin.profile.DefaultUserFormatMapper] Mapping type 'profileLinkExternal' to module 'jira.user.format:profile-link-external-user-format'.
        2015-07-22 21:01:54,795 http-8080-Processor22 INFO [jira.plugin.profile.DefaultUserFormatMapper] Mapping type 'profileLinkActionHeader' to module 'jira.user.format:profile-link-action-header-user-format'.
        2015-07-22 21:01:54,807 http-8080-Processor22 INFO [jira.plugin.profile.DefaultUserFormatMapper] Mapping type 'fullProfile' to module 'jira.user.format:full-profile-user-format'.
        2015-07-22 21:01:55,640 http-8080-Processor22 ERROR [atlassian.jira.util.FileFactory] Unable to delete directory /data/jira3135/indexes/comments
        2015-07-22 21:01:55,640 http-8080-Processor22 ERROR [atlassian.jira.util.FileFactory] Unable to delete directory /data/jira3135/indexes/issues
        2015-07-22 21:01:55,641 http-8080-Processor22 ERROR [atlassian.jira.util.FileFactory] Unable to delete directory /data/jira3135/indexes/plugins
        2015-07-22 21:01:55,867 http-8080-Processor22 INFO [jira.issue.index.DefaultIndexManager] Reindexing all issues
        2015-07-22 21:01:55,871 http-8080-Processor22 WARN [atlassian.jira.util.LuceneUtils] Directory /data/jira3135/indexes/issues does not exist - perhaps it was deleted?  Creating..
        2015-07-22 21:01:55,873 http-8080-Processor22 WARN [atlassian.jira.util.LuceneUtils] Directory /data/jira3135/indexes/comments does not exist - perhaps it was deleted?  Creating..
        2015-07-22 21:02:13,033 http-8080-Processor22 WARN [atlassian.jira.util.LuceneUtils] Directory /data/jira3135/indexes/entities/searchrequest does not exist - perhaps it was deleted?  Creating..
        2015-07-22 21:02:13,257 http-8080-Processor22 WARN [atlassian.jira.util.LuceneUtils] Directory /data/jira3135/indexes/entities/portalpage does not exist - perhaps it was deleted?  Creating..
        2015-07-22 21:02:13,889 http-8080-Processor22 ERROR [atlassian.jira.upgrade.ConsistencyCheckImpl] Attachments are turned on, but attachment path [/data/jira_3_12/attachments] invalid - disabling attachments
        2015-07-22 21:02:13,904 http-8080-Processor22 INFO [atlassian.jira.upgrade.UpgradeManagerImpl] Detected that an upgrade is needed; existing data at build 299
        2015-07-22 21:02:13,907 http-8080-Processor22 INFO [atlassian.jira.upgrade.UpgradeManagerImpl] Doing Upgrade...
        2015-07-22 21:02:13,915 http-8080-Processor22 INFO [atlassian.jira.upgrade.UpgradeManagerImpl] Performing Upgrade Task: Set application property 'webwork.multipart.maxSize' to default value if not set or invalid value
        2015-07-22 21:02:13,936 http-8080-Processor22 INFO [atlassian.jira.upgrade.UpgradeManagerImpl] Upgrade Task: 'Set application property 'webwork.multipart.maxSize' to default value if not set or invalid value' succeeded
        2015-07-22 21:02:13,936 http-8080-Processor22 INFO [atlassian.jira.upgrade.UpgradeManagerImpl] Setting current build number on to 317
        2015-07-22 21:02:13,944 http-8080-Processor22 INFO [atlassian.jira.upgrade.UpgradeManagerImpl] Performing Upgrade Task: Initialise favourite filters - make each filter a favourite of its owner.
        2015-07-22 21:02:17,822 http-8080-Processor22 INFO [jira.upgrade.tasks.UpgradeTask_Build319] Could not find author 'fpy' for filter with id '10040'
        2015-07-22 21:02:17,990 http-8080-Processor22 INFO [atlassian.jira.upgrade.UpgradeManagerImpl] Upgrade Task: 'Initialise favourite filters - make each filter a favourite of its owner.' succeeded
        2015-07-22 21:02:17,990 http-8080-Processor22 INFO [atlassian.jira.upgrade.UpgradeManagerImpl] Setting current build number on to 319
        2015-07-22 21:02:17,995 http-8080-Processor22 INFO [atlassian.jira.upgrade.UpgradeManagerImpl] Performing Upgrade Task: Initialise Share Permissions.  Move old shares to new shares.
        2015-07-22 21:02:18,003 http-8080-Processor22 INFO [atlassian.jira.upgrade.UpgradeManagerImpl] Upgrade Task: 'Initialise Share Permissions.  Move old shares to new shares.' succeeded
        2015-07-22 21:02:18,003 http-8080-Processor22 INFO [atlassian.jira.upgrade.UpgradeManagerImpl] Setting current build number on to 321
        2015-07-22 21:02:18,008 http-8080-Processor22 INFO [atlassian.jira.upgrade.UpgradeManagerImpl] Performing Upgrade Task: Migrating the old JIRA UI colors to the new JIRA 3.13 colors
        2015-07-22 21:02:18,008 http-8080-Processor22 INFO [jira.upgrade.tasks.UpgradeTask_Build322] Custom color detected for jira.lf.menu.bgcolour : #336699
        2015-07-22 21:02:18,021 http-8080-Processor22 INFO [atlassian.jira.upgrade.UpgradeManagerImpl] Upgrade Task: 'Migrating the old JIRA UI colors to the new JIRA 3.13 colors' succeeded
        2015-07-22 21:02:18,021 http-8080-Processor22 INFO [atlassian.jira.upgrade.UpgradeManagerImpl] Setting current build number on to 322
        2015-07-22 21:02:18,025 http-8080-Processor22 INFO [atlassian.jira.upgrade.UpgradeManagerImpl] Performing Upgrade Task: Initialise favourite dashboards - make each dashboard a favourite of its owner.
        2015-07-22 21:02:18,272 http-8080-Processor22 INFO [jira.upgrade.tasks.UpgradeTask_Build325] Could not find owner 'cmcgann' for dashboard with id '10030'
        2015-07-22 21:02:18,272 http-8080-Processor22 INFO [jira.upgrade.tasks.UpgradeTask_Build325] Could not find owner 'fpy' for dashboard with id '10060'
        2015-07-22 21:02:18,423 http-8080-Processor22 INFO [jira.upgrade.tasks.UpgradeTask_Build325] Could not find owner 'kanna' for dashboard with id '10040'
        2015-07-22 21:02:18,618 http-8080-Processor22 INFO [atlassian.jira.upgrade.UpgradeManagerImpl] Upgrade Task: 'Initialise favourite dashboards - make each dashboard a favourite of its owner.' succeeded
        2015-07-22 21:02:18,618 http-8080-Processor22 INFO [atlassian.jira.upgrade.UpgradeManagerImpl] Setting current build number on to 325
        2015-07-22 21:02:18,625 http-8080-Processor22 INFO [atlassian.jira.upgrade.UpgradeManagerImpl] Performing Upgrade Task: Reindexing all data in JIRA to include Favourites.
        2015-07-22 21:02:18,648 http-8080-Processor22 INFO [jira.util.index.IndexLifecycleManager$Composite] Reindex All starting...
        2015-07-22 21:02:18,650 http-8080-Processor22 INFO [jira.upgrade.tasks.UpgradeTask_Build326] Re-indexing is 0% complete. Current index: Issue
        2015-07-22 21:02:18,654 http-8080-Processor22 INFO [jira.issue.index.DefaultIndexManager] Reindexing all issues
        2015-07-22 21:02:18,809 indexerPool-2-thread-5 INFO [jira.upgrade.tasks.UpgradeTask_Build326] Re-indexing is 1% complete. Current index: Issue
        2015-07-22 21:02:18,855 indexerPool-2-thread-10 INFO [jira.upgrade.tasks.UpgradeTask_Build326] Re-indexing is 2% complete. Current index: Issue
        2015-07-22 21:02:18,899 indexerPool-2-thread-7 INFO [jira.upgrade.tasks.UpgradeTask_Build326] Re-indexing is 3% complete. Current index: Issue
        2015-07-22 21:02:18,945 indexerPool-2-thread-7 INFO [jira.upgrade.tasks.UpgradeTask_Build326] Re-indexing is 4% complete. Current index: Issue
        2015-07-22 21:02:19,012 indexerPool-2-thread-7 INFO [jira.upgrade.tasks.UpgradeTask_Build326] Re-indexing is 5% complete. Current index: Issue
        .
        .
        .
        2015-07-22 21:02:26,164 indexerPool-2-thread-5 INFO [jira.upgrade.tasks.UpgradeTask_Build326] Re-indexing is 95% complete. Current index: Issue
        2015-07-22 21:02:26,232 indexerPool-2-thread-5 INFO [jira.upgrade.tasks.UpgradeTask_Build326] Re-indexing is 96% complete. Current index: Issue
        2015-07-22 21:02:26,316 indexerPool-2-thread-9 INFO [jira.upgrade.tasks.UpgradeTask_Build326] Re-indexing is 97% complete. Current index: Issue
        2015-07-22 21:02:26,771 indexerPool-2-thread-3 INFO [jira.upgrade.tasks.UpgradeTask_Build326] Re-indexing is 98% complete. Current index: Issue
        2015-07-22 21:02:27,261 http-8080-Processor22 INFO [jira.util.index.IndexLifecycleManager$Composite] Reindex took: 8607ms. Indexer: DefaultIndexManager: paths: [/data/jira3135/indexes/issues, /data/jira3135/indexes/comments]
        2015-07-22 21:02:27,263 http-8080-Processor22 INFO [jira.upgrade.tasks.UpgradeTask_Build326] Re-indexing is 98% complete. Current index: SearchRequest
        2015-07-22 21:02:27,268 http-8080-Processor22 WARN [atlassian.jira.util.LuceneUtils] Directory /data/jira3135/indexes/entities/searchrequest does not exist - perhaps it was deleted?  Creating..
        2015-07-22 21:02:27,293 http-8080-Processor22 INFO [jira.upgrade.tasks.UpgradeTask_Build326] Re-indexing is 99% complete. Current index: SearchRequest
        2015-07-22 21:02:27,308 http-8080-Processor22 INFO [jira.upgrade.tasks.UpgradeTask_Build326] Re-indexing is 99% complete. Current index: PortalPage
        2015-07-22 21:02:27,312 http-8080-Processor22 WARN [atlassian.jira.util.LuceneUtils] Directory /data/jira3135/indexes/entities/portalpage does not exist - perhaps it was deleted?  Creating..
        2015-07-22 21:02:27,377 http-8080-Processor22 INFO [jira.upgrade.tasks.UpgradeTask_Build326] Re-indexing is 100% complete. Current index: PortalPage
        2015-07-22 21:02:27,384 http-8080-Processor22 INFO [jira.util.index.IndexLifecycleManager$Composite] Reindex took: 115ms. Indexer: SharedEntityIndexManager: paths: [/data/jira3135/indexes/entities/portalpage, /data/jira3135/indexes/entities/searchrequest]
        2015-07-22 21:02:27,384 http-8080-Processor22 INFO [jira.upgrade.tasks.UpgradeTask_Build326] Re-indexing is 100% complete. Current index:
        2015-07-22 21:02:27,384 http-8080-Processor22 INFO [jira.util.index.IndexLifecycleManager$Composite] Reindex All complete. Total time: 8722ms.
        2015-07-22 21:02:27,389 http-8080-Processor22 INFO [atlassian.jira.upgrade.UpgradeManagerImpl] Upgrade Task: 'Reindexing all data in JIRA to include Favourites.' succeeded
        2015-07-22 21:02:27,389 http-8080-Processor22 INFO [atlassian.jira.upgrade.UpgradeManagerImpl] Setting current build number on to 326
        2015-07-22 21:02:27,397 http-8080-Processor22 INFO [atlassian.jira.upgrade.UpgradeManagerImpl] Upgrade succeeded! Setting data build number to 360
        2015-07-22 21:02:27,469 JiraQuartzScheduler_Worker-0 WARN [service.services.export.ExportService] Backup directory /data/jira_3_12/backup does not exist
        

        Paths It appears that the upgraded JIRA will still look for the attachments and the backup locations in the original places. So I created /data/jira_3_12/backup and untarred the original attachments to /data/jira_3_12 and then everything worked (including attachements) in the new JIRA.

    31. I then used the upgraded JIRA to generate a new XML backup and stored it in /data/original/3.13.5 along with another tar of the files in /data/jira_3_12/attachments.
    32. I then shutdown the JIRA server. I should be ready to move on to version 4 upgrade WHEW
    33. So, before moving on, I decided that it would be a really good idea to spin up a new Crowd instance to get rid of the :8443 in the URL and to move off of RedHat per IS requests. I have a ticket in for a new VM and a new database to try to get this going. I am waiting on that before moving on.
    34. Pat created the VM and Neil created the database.
    35. I logged into auth.mbari.org (name of the VM) and downloaded crowd which I unzipped to the /opt directory
    36. I then created a /data/crowd directory and gave my account permissions on it and then edited the /opt/atlassian..../crowd-webapp/WEB-INF/classes/crowd-init.properties file to set that as the crowd home directory.
    37. The instructions say to download the JDBC driver, but they already have JTDS 1.2.7 in the download so I did not do anything.
    38. You have to manually connect up CrowdID to a database as they setup wizard does not currently do this.
        1. They say to download the driver, but again 1.2.7 was there so I did nothing.
        2. I edited the /opt/atlassian.../apache-tomcat/conf/Catalina/localhost/openidserver.xml to look like:

           <Context docBase="../../crowd-openidserver-webapp">
           
               <Resource name="jdbc/CrowdIDDS" auth="Container" type="javax.sql.DataSource"
                         username="DB_Collaboration"
                         password="ask Kevin"
                         driverClassName="net.sourceforge.jtds.jdbc.Driver"
                         url="jdbc:jtds:sqlserver://dione.mbari.org:51001/CrowdID;domain=SHORE;useNTLMv2=TRUE"
                       />
           
               <!-- NOTE: When a database server reboots or their is a network failure all the connections in the
               * connection pool are broken and normally this requires a Application Server reboot. If you include the
               * parameter validationQuery="{QUERY FOR YOUR DB HERE} as show below a new connection is created to replace it.
               * For more information see http://confluence.atlassian.com/display/JIRA/Surviving+Connection+Closures
               *
               * validationQuery="Select 1"
               -->
           
               <!-- NOTE: If you use a database other than hsqldb:
               * delete the minEvictableIdleTimeMillis and timeBetweenEvictionRunsMillis attributes
               -->
           
           </Context>
           

        3. I edited the /opt/atlassian.../build.properties files to look like:

           # Modify the attributes of this file to quickly adjust the deployment values of Crowd.
           
           # The Hibernate database dialect to use. See https://confluence.atlassian.com/display/CROWD/Connecting+Crowd+to+a+Database
           hibernate.dialect=org.hibernate.dialect.SQLServerDialect
           
           # The Hibernate transaction factory to use. See https://confluence.atlassian.com/display/CROWD/Configuring+Crowd
           hibernate.transaction.factory_class=org.hibernate.transaction.JDBCTransactionFactory
           
           # The http port you wish to run crowd from, ie: http://localhost:8095/crowd
           crowd.tomcat.connector.port=8095
           
           # Tomcat requires a unique port for shutdown
           crowd.tomcat.shutdown.port=8020
           
           # Crowd context root
           crowd.url=http://localhost:8095/crowd
           
           # Demo context root
           demo.url=http://localhost:8095/demo
           
           # OpenID server context root
           openidserver.url=http://localhost:8095/openidserver
           

        4. I then ran the build.sh script in the root of /opt/atlassian...
    39. I fired up crowd using the /opt/atlassian.../start_crowd.sh script
    40. I then went to http://auth.mbari.org:8095/crowd to kick off the start up wizard
    41. I grabbed a new eval license from my account on atlassian and pasted into the license page.
    42. I selected "New install" on the next page.
    43. I configured the JDBC connection using this connection URL with user DB_Collaboration

        jdbc:jtds:sqlserver://dione.mbari.org:51001/Crowd;domain=SHORE;useNTLMv2=TRUE
        

    44. I left the "Options" as they came up

        Paths Not sure if this is a problem, but because I started the set up using auth.mbari.org, it set the Base URL to http://auth.mbari.org:8095/crowd instead of localhost. Hope that is not a problem. We will see.

    45. I configured the email connection using the settings from here and I used my network login (probably shouldn't be doing that ... not sure where it stores my password, but I am assuming in the DB).
    46. For the local admin account, I created a user named 'crowdadm' so it would not clash with my LDAP account. See Kevin Gomes for password information.
    47. I checked the OpenID server as an integrated application
    48. It then took me to the login page and I logged in using the newly minted admin account. Seemed all is well so far.
    49. I visited the openidserver URL as well and that seemed OK.
    50. I decided to wait on configuring the MBARI LDAP directory until I got everything with SSL working.
    51. Now the next step was to follow the directions to configure Crowd to run over SSL found here
    52. I shutdown crowd. Note that the stop script does not shutdown things correctly and I noticed the crowd app running as root. That should not be if I started as kgomes. Not sure what is up with that.
    53. Now Joe had already configured SSL once, so I used his connector configuration in the server.xml file and so the final file looked like:

        <?xml version="1.0" encoding="UTF-8" standalone="no"?>
        <Server port="8020" shutdown="SHUTDOWN">
        
            <Service name="Catalina">
        
                <Connector
                    SSLEnabled="true"
                    URIEncoding="UTF-8"
                    acceptCount="100"
                    address="134.89.2.12"
                    ciphers="TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_RC4_128_SHA,TLS_RSA_WITH_3DES_EDE_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_RC4_128_MD5,TLS_RSA_WITH_RC4_128_SHA"
                    clientAuth="false"
                    compressableMimeType="text/html,text/xml,text/css,test/javascript,application/javascript,application/x-javascript,application/ecmascript,text/ecmascript"
                    compression="on"
                    compressionMinSize="2048"
                    connectionTimeout="20000"
                    disableUploadTimeout="true"
                    enableLookups="false"
                    keystoreFile="/etc/httpd/auth.mbari.org.jks"
                    keystorePass="check with IS"
                    keystoreType="JKS"
                    maxHttpHeaderSize="8192"
                    maxThreads="150"
                    minSpareThreads="25"
                    noCompressionUserAgents="gozilla, traviata"
                    port="8095"
                    protocol="HTTP/1.1"
                    redirectPort="8443"
                    scheme="https"
                    secure="true"
                    sslEnabledProtocols="TLSv1, TLSv1.1, TLSv1.2"
                    sslProtocol="TLS"
                    useBodyEncodingForURI="true"/>
        
                <Engine defaultHost="localhost" name="Catalina">
                    <Host appBase="webapps" autoDeploy="true" name="localhost" unpackWARs="true"/>
                </Engine>
        
                <!-- To connect to an external web server (typically Apache) -->
                <!-- Define an AJP 1.3 Connector on port 8009 -->
                <!--
                    <Connector port="8009" enableLookups="false" redirectPort="8443" protocol="AJP/1.3" />
                -->
            </Service>
        
            <!-- Security listener. Documentation at /docs/config/listeners.html
            <Listener className="org.apache.catalina.security.SecurityListener" />
            -->
            <!--APR library loader. Documentation at /docs/apr.html -->
            <Listener SSLEngine="on" className="org.apache.catalina.core.AprLifecycleListener"/>
            <!--Initialize Jasper prior to webapps are loaded. Documentation at /docs/jasper-howto.html -->
            <Listener className="org.apache.catalina.core.JasperListener"/>
            <!-- Prevent memory leaks due to use of particular java/javax APIs-->
            <Listener className="org.apache.catalina.core.JreMemoryLeakPreventionListener"/>
            <Listener className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener"/>
            <Listener className="org.apache.catalina.core.ThreadLocalLeakPreventionListener"/>
        
        </Server>
        

    54. I then edited the /data/crowd/crowd.properties to look like:

        #Sat Aug 01 09:05:15 PDT 2015
        session.lastvalidation=session.lastvalidation
        session.tokenkey=session.tokenkey
        crowd.server.url=https\://localhost\:8443/crowd/services/
        application.name=crowd
        http.timeout=30000
        session.isauthenticated=session.isauthenticated
        application.login.url=https\://localhost\:8443/crowd/console/
        session.validationinterval=0
        application.password=Y1Xp3OorCmsOP4eruL1dmH
        

        One thing to note here is that based on a comment from the SSL configuration page at atlassian (Steve's comment), you are supposed to leave all the host names the same. For example, if the file says localhost, leave it localhost. So this created a bit of a problem based on the fact that I had left the base URL pointing to auth.mbari.org in the wizard steps above. That step wrote auth.mbari.org to the /data/crowd/crowd.properties. All the other files reference localhost, so to be consistent, I changed auth.mbari.org to localhost in the /data/crowd/crowd.properties file. We will see if this works.

    55. Per the instructions on the atlassian page (referenced above), I also edited the build.properties file and the <Crowd-install>/client/conf/crowd.properties files before I restarted and used the SSL URLs
    56. build.properties:

        # Modify the attributes of this file to quickly adjust the deployment values of Crowd.
        
        # The Hibernate database dialect to use. See https://confluence.atlassian.com/display/CROWD/Connecting+Crowd+to+a+Database
        hibernate.dialect=org.hibernate.dialect.SQLServerDialect
        
        # The Hibernate transaction factory to use. See https://confluence.atlassian.com/display/CROWD/Configuring+Crowd
        hibernate.transaction.factory_class=org.hibernate.transaction.JDBCTransactionFactory
        
        # The http port you wish to run crowd from, ie: http://localhost:8095/crowd
        crowd.tomcat.connector.port=8095
        
        # Tomcat requires a unique port for shutdown
        crowd.tomcat.shutdown.port=8020
        
        # Crowd context root
        crowd.url=https://localhost:8443/crowd
        
        # Demo context root
        demo.url=https://localhost:8443/demo
        
        # OpenID server context root
        openidserver.url=https://localhost:8443/openidserver
        

    57. crowd.properties (client)

        application.name                        crowd
        application.password                    password
        application.login.url                   https://localhost:8443/crowd/console/
        
        crowd.server.url                        https://localhost:8443/crowd/services/
        crowd.base.url                          https://localhost:8443/crowd/
        
        session.isauthenticated                 session.isauthenticated
        session.tokenkey                        session.tokenkey
        session.validationinterval              2
        session.lastvalidation                  session.lastvalidation
        

    58. Although not stated, I am assuming you would need to run the build.sh script to push the build.properties changes to their proper places, so I did that. Note that before doing that, I know that it will clobber the server.xml changes I made, so I made a copy of that file and diff'd them after and then rolled the previous changes to the new server.xml file. Actually, amazingly enough, it seems to have done the connector entry correctly so I left it after running the build.sh script.
    59. Crossed my fingers and then restarted crowd. I tailed the catalina.out file and did not see any stack traces so that is a good sign!
    60. I visited https://auth.mbari.org:8443/crowd first. It could not find that page, but I suspect that is because I am browsing from the outside, so I tried just https://auth.mbari.org/crowd and got a service unavailable. I am suspecting that this is a combination of firewall and proxy pass and I will send this info to Joe. From what I can see on the crowd side, it seems like the server started cleanly, we just can't get to it. I tried to reach it from a browser on the machine itself too (through VNC) with the same service not available.
    61. Here are the notes from Joe after he fixed it! Wooohooo!

        Hey Kevin,
        
        Thanks for starting clean! I had to make a few adjustments. 
        
        1-I modified the server.xml file in /opt/atlassian-crowd-2.8.3/apache-tomcat/conf/server.xml so there are two connectors per the instructions on the Atlassian site. I have backed up this good server.xml file in /etc/temp/ if you want to browse it to see what I did. Of note is that I removed all the jargon referencing the types of ciphers available to simplify things for now.
        
        2-I modified /data/crowd/crowd.properties to have 
        
        crowd.server.url=https\://localhost\:8443/crowd/services/
        application.login.url=https\://localhost\:8443/crowd/console/
        
        But that would cause my login to error with an error saying it was unable to reach the authentication server. I scratched my head for a bit. When I revert the values to just using non-SSL and try to log in, I just get an "invalid login" (I don't know the crowdadm password). So I worked under the assumption that if I can configure SSL to get an "invalid login" when logging in then it would work when provided real credentials.
        
        So, I then changed /data/crowd/crowd.proprties to:
        
        crowd.server.url=https\://auth.mbari.org\:8443/crowd/services/
        application.login.url=https\://auth.mbari.org\:8443/crowd/console/
        
        And now when I try to log in with SSL it says "invalid login". Strange because all the other values I can find only show "localhost" .. in any case...
        
        Can you try to log in now? 
        

    62. Next I moved on to configuring the connection to MBARI's LDAP server to enable our logins through Crowd and CrowdID
    63. I clicked on "Add Directory" in crowd.
    64. I selected "Connector" then clicked Next
    65. I put ldap.shore.mbari.org as the name of the server
    66. I selected "Use memberOf for group memberships"
    67. I used "OU=AllUsers,DC=shore,DC=mbari,DC=org" for the Base DN
    68. I used "CN=LDAPbind,OU=Special,OU=AllUsers,DC=shore,DC=mbari,DC=org" for the Username (talk to Pat Allen for password)
    69. I tested the connection (button click) and it passed.
    70. I de-selected all the capabilities of the connector as it is a ready only connector and then saved it. It synchronized correctly!
    71. At first, I could not login using my MBARI credentials, but after going to the "crowd" application in crowd (logged in as the local admin), I had to add the LDAP directory and configure it to "Allow all to authenticate", then I was able to login. After this, the last step was to get this to run as a different user and lock down various directories. I went through the entire directory structure /opt/atlassian... and set up so that root owned all read-only locations and DB_Collaboration (account set up by IS) owned the other stuff. I also gave full ownership to the /data/crowd directory to DB_Collaboration so it could write there. Pat set up a script to start on boot and after a little tweaking, it now starts on boot.

        CrowdID log file One thing that came up here was that when the crowdID application ran, it tried to write a log file to the location where the process was launched from (which is /opt/atlassian...). This is a bad thing and I figured out that I could change that location by changing the file /opt/atlassian-crowd-2.8.3/crowd-openidserver-webapp/WEB-INF/classes/log4j.properties and hardcoding the /data/crowd/logs/atlassian-crowd-openid-server.log and then restarted the application.

    72. Another note is the when an application tried to use the OpenID application, it would get redirected to localhost. I changed the /opt/atlassian.../crowd-openidserver-webapp/WEB-INF/classes/crowd.properties file to look like:

        #Sat Aug 01 10:03:18 PDT 2015
        session.lastvalidation=session.lastvalidation
        session.tokenkey=session.tokenkey
        crowd.server.url=http\://localhost\:8095/crowd/services/
        application.name=crowd-openid-server
        #application.login.url.template=http\://localhost\:8095/openidserver?returnToUrl\=${RETURN_TO_URL}
        application.login.url.template=https\://auth.mbari.org/openidserver?returnToUrl\=${RETURN_TO_URL}
        session.isauthenticated=session.isauthenticated
        #application.base.url=http\://localhost\:8095/openidserver
        application.base.url=https\://auth.mbari.org/openidserver
        #application.login.url=http\://localhost\:8095/openidserver
        application.login.url=https\://auth.mbari.org/openidserver
        session.validationinterval=0
        application.password=password
        

        and that seems to have fixed it.

18. It is finally time to move on to the version 4 upgrade ... holy crap. I first went to the new crowd install (auth.mbari.org) and logged in as the crowdadm.
19. I clicked on Applications, then on Add Application
20. I selected JIRA from the Application type drop-down
21. I entered jira445 as the username. Ask Kevin about the password.
22. I used http://bugs.shore.mbari.org:8081 as the URL
23. I used 134.89.12.31 as the IP address.
24. I selected only the MBARI LDAP directory.
25. Then I selected "Allow all users to authenticate"
26. Then I clicked on "Add Application"
27. I VNC'd into bugs.mbari.org. As it turns out, for Linux, there is an installer program to download. I downloaded the .bin for 64 bit Linux installer and moved it to the jira-upgrade directory.
28. I chmod'd the file to make it executable and ran it. It gave me a warning about not being root, but I went ahead with it.
29. It asked for the JIRA home and data directory, which I specified as /opt/jira4 and /data/jira445.
30. For the ports, I specified 8180 and 8105 (HTTP and control respectively). It then extracted all the files and launched JIRA. It said if finished, so I opened a local browser to http://localhost:8180 which kicked off the start up wizard.
31. I specified the external database using:
    1. solstice2.shore.mbari.org (server)
    2. 1433 (port)
    3. jira4 (database)
    4. DB_Collaboration (username)
    5. (password ask Kevin)
    6. dbo (schema)
32. But all this failed as it seems to just want to try and use the SQL server authentication instead of domain. I will have to do it manually.
33. I stopped the server using the bin/stop-jira.sh script.
34. I created and edited /data/jira445/dbconfig.xml and made it look like the following:

    ?xml version="1.0" encoding="UTF-8"?>
    
    <jira-database-config>
      <name>defaultDS</name>
      <delegator-name>default</delegator-name>
      <database-type>mssql</database-type>
      <schema-name>jiraschema</schema-name>
      <jdbc-datasource>
        <url>jdbc:jtds:sqlserver://solstice2.shore.mbari.org:1433/Jira4;domain=SHORE;useNTLMv2=true</url>
        <driver-class>net.sourceforge.jtds.jdbc.Driver</driver-class>
        <username>DB_Collaboration</username>
        <password>(ask Kevin)</password>
        <pool-size>15</pool-size>
      </jdbc-datasource>
    </jira-database-config>
    

35. I then started it again using bin/start-jira.sh and tailed the catalina.out file. Got a bunch of errors related to the schema 'jiraschema', I edited the file and changed the schema to 'dbo' and restarted. That seemed to do it. There was one stack trace for some iCal plugin, but looks OK other than that.
36. I browsed back to localhost:8180 and the wizard moved to step 2. There was an option to import existing data bit without the crowd connection, I thought I should set it up manually, connect to crowd, then import. I generated an evaluation license, called the app "MBARI JIRA4" and change the server in the url to bugs.shore.mbari.org
37. For the admin, I created an account called 'jiraadm' (ask Kevin for password).
38. Since this is a temporary system, I left the email system disabled.
39. I logged in as jiraadm, went to Administration, then Users, then clicked on Add Directory and chose Atlassian Crowd. Note that I had to set the server URL to http://auth.mbari.org:8095/crowd or I would have had to configure all this SSL crap that I did not want to do for this temporary install.
40. It tested successfully, I clicked Save and it went through a 13 second sync, whew!
41. I then went to System->Import and Export->Restore System
42. I copied the jira-upgrade-3.13.5.zip file from the previous version export into /data/jira445/import and then entered that file name along with the new evaluation license again.
43. I worked through progress bar after I clicked on Restore (it took a really long time).
44. I then stopped, restarted and tailed the log file.
45. I am thinking now I should have put the attachments in the import attachments directory, but I am hoping I can just copy them to the data/attachments directory.
46. UG! I got some error during the import. The exception read: "JIRA is unable to migrat the User Directory configuration because external users exist but the osuser.xml file is not available". It then gave me a link to a doc that talked about making the old user files available before the upgrade ... crap. So I needed to copy the osuser.xml and crowd.properties file from atlassian-jira/WEB-INF/classes directory on the old install to the same directory on the new install ... sigh. This means I am going to blow away everything and start over.
47. I shutdown jira4
48. I dropped all things in the database and deleted all content in the /data/jira445 directory (except for the dbconfig.xml file).
49. I also removed the temp, logs (actually you have to leave the directory, just clear the files) and the work/Catalina/localhost directories from the jira installation.
50. I then copied the osuser.xml and the crowd.properties files from the 3.13.5 install to the 4 install.
51. I edited the crowd.properties file in hopes that I could point it to the new crowd install on auth.mbari.org and it would work, but we will see.
52. I then started jira and tailed the log file.
53. All looked OK (other than iCal plugin stack trace again), so I went to localhost:8180 and got step 2 of the wizard. I used the same info as before.
54. I logged in as the local admin account and it looks like the system picked up the crowd connection, but lets see what server it used! Hey it used the one I edited into the file! Sweet ... now let's see if the import works.
55. I copied the 3.13.5 zip file to the import directory again and this time, I untarred the attachments into the import/attachments directory.
56. I kicked off the restore as before and it worked through it fine.
57. Shutdown and restarted system, tailing the log file and then went to localhost:8180
58. I can see issues (before logging in) and it all looks good!! The attachments did not move over from the import directory, so I copied the tar file from /data/jira445/import to /data/jira445/data and then untarred it there, then removed the tar file and the import zip file from the import directory.
59. Now I will try to login using my MBARI account and OMG it actually worked!!! (it even gave my kgomes account Admin privs)
60. I then performed an export and copied those file to the /data/backups/4.4.5 directory (also created a TAR of the attachments and put there too).
61. Now on to version 5!
62. OK, so something strange is happening. After the imports, the server ID goes back to the one that is on our current production server, which must mean it is using our current license key (which does not match the server ID, BTW). Oh well, I will press on!
63. I created a /data/jira5211 directory as well as a /opt/jira5 directory. Knowing what I know now and reading through the install instructions, it appears that I need to create a dbconfig.xml file manually, so I did that using:

    <jira-database-config>
    <name>defaultDS</name>
    <delegator-name>default</delegator-name>
    <database-type>mssql</database-type>
    <schema-name>dbo</schema-name>
    <jdbc-datasource>
      <url>jdbc:jtds:sqlserver://solstice2.shore.mbari.org:1433/Jira5;domain=SHORE;useNTLMv2=true</url>
      <driver-class>net.sourceforge.jtds.jdbc.Driver</driver-class>
      <username>DB_Collaboration</username>
      <password>(ask Kevin)</password>
      <pool-min-size>20</pool-min-size>
      <pool-max-size>20</pool-max-size>
      <pool-max-wait>30000</pool-max-wait>
      <pool-max-idle>20</pool-max-idle>
      <pool-remove-abandoned>true</pool-remove-abandoned>
      <pool-remove-abandoned-timeout>300</pool-remove-abandoned-timeout>
     
      <validation-query>select 1</validation-query>
      <min-evictable-idle-time-millis>60000</min-evictable-idle-time-millis>
      <time-between-eviction-runs-millis>300000</time-between-eviction-runs-millis>
     
      <pool-test-while-idle>true</pool-test-while-idle>
      <pool-test-on-borrow>false</pool-test-on-borrow>
    </jdbc-datasource>
    </jira-database-config>
    

64. I then changed the mode to executable on the installer download and ran that.
65. I had to choose a "custom install" this time through, but the properties were similar after that (ports I used were 8280 and 8205)
66. I then browsed to localhost:8280
67. I dropped me to a wizard where I define the title as "MBARI JIRA5", and changed host to bugs.shore.mbari.org (from localhost)
68. This license was a little different in that is just asked for my Atlassian username and password and fetched a new license for me.
69. For the admin account, I used the same 'jiraadm' account
70. Left email notification disabled.
71. I created a new application in crowd for JIRA 5 and used same account info as for 4.
72. In JIRA, I went to Administration->Users->User Directories and then added a directory as I had done before.
73. All went well and the sync happened.
74. I then went to Administration->System->Import and Export->Restore System
75. I copied the backup of 4.4.5 to the /data/jira5211/import directory and then specified that file name. I did not specify a license as it seems to use the old one and it said so in the text below the box.
76. Clicked on restore and while it was restoring, I untarred the attachments to the /data/jira5211/data directory
77. After the restore, I shutdown and restarted JIRA tailing the log file.
78. Browsed to localhost:8280 and ... success! I see issues before logging in and ... my MBARI login worked, I was admin and all is good!!!!
79. As with previous version, I ran a backup of the DB and attachments and placed in /data/backups/5.2.11
80. I poked around a little and there seems to be an issue in the comments that they are still referencing oceana??? I will have to look into this.
81. I then re-did the process once again for version 6.4.9. I will only put notes about things that are dramatically different below:
    1. It looks like the dbconfig.xml file is the same as it is for version 5, so I just copied and edited to point to Jira6 DB.
    2. I used ports 8380 and 8305

       Collation The DB needs to be using a specific collation that it's not, I will have to correct that on the production run

    3. It gave me a choice on "how I wanted to use JIRA" and I chose the default (top) one which was just JIRA.
    4. Something did not go well on the restore (got to 90%) from backup up and the server seems to have crashed, but it looks like it tried to restart?
    5. I forced a stop and start and tailed the log file. Could it be related to the collation issue? Upon restart it re-ran the indexing. Looks like it worked OK, let me login with my MBARI account.
    6. Interesting, the comments pointing to oceana seems to have fixed itself in the step of the upgrade.
    7. Another interesting note, when I went to the Admin->System->General configuration, it had the base URL as oceana, that would explain it. So I edited that to bugs.shore.mbari.org (it also made me change the Mode to private, which makes sense since authentication is external).
    8. I went back to the 3, 4, and 5 install and changed the base URL there too. That fixed that issue.
82. I then sent an email to all hands giving the URLs for folks to look at.
83. While folks were looking over the upgrade instances, I went ahead and created the cloud instance at Atlassian so I could test upload the JIRA backup from 6.4.9

    Disable Remote Crowd Directory As a part of the test import, I discovered that you have to disable the remote crowd directory through User Management->User Directories before you do the backup/export.

84. You basically do a backup of the system, tar up the attachments and then push those files to the cloud instance through WebDAV. Then you choose those files to do a 'JIRA Import'. The attachments did not work and I had to leave those de-selected and then submitted a ticket for that to be done.
85. It did seem to import all the users from our LDAP system, so I had to go through and 'Deactivate' all the users that I did not think would login. The billing adjusts fine to that, so that seems tractable. I am still working on seeing how users login to their imported accounts and if you can link BitBucket accounts to JIRA.

The Production (Final) Migration

The day is finally here, the production JIRA migration. Here are the steps I took:

1. Logged into oceana as root
2. Edited the /opt/jira/conf/server.xml and commented out the Connector section that had the port of 8010 to shut it off from the normal serving route
3. I uncommented the 8082 port connector and the 8443 port connector so that I could still get to the server.
4. I stopped and started the JIRA server and in the log file I got a "keystore was tampered with..." which is not surprising.
5. I could then browser over to http://oceana.mbari.org:8082/jira
6. Then through the Administration console, I did an XML backup (file named final-jira-migration-backup-2015-08-21) and selected the zip option
   1. I had to create a /tmp/jira-backup directory and give DB_Collaboration:coladm ownership for the backup to happen ... sigh
7. I created the directory /root/jira-upgrade/final-2015-08-21 and moved the backup from /tmp/jira-backup to that location
8. I then shut down JIRA (hopefully for the LAST time!!!)
9. I logged out of oceana
10. I logged into bugs.shore.mbari.org as me
11. Due to a patch and reboot, all the JIRA servers were down, which was fine.
12. I cd'd to /opt/atlassian-jira-enterprise-3.13.5-standalone
13. I wanted to clean things up so I cd'd to logs and removed all the log files
14. I then wanted to remove the deployed web application so I could start clean so I changed to ../work and deleted the entire Catalina directory
15. Using Aqua Data Studio, I deleted all the tables in the Jira_Temp database on solstice2
16. Back on bugs, I scp'd the backup zip file and the attachments file to the /data/backups/3.12/final-upgrade-2015-08-21 directory
17. I cd'd to the /data/jira3135 directory and deleted the attachments and indexes directories and then created empty directories for those again.
18. Since the first import will look for attachments in /data/jira_3_12, I cd'd to that directory and deleted the attachments directory there.
19. I then copied the attachments tar I scp'd over and untarred it in that location.
20. I then started up JIRA (version 3.13.5) using /opt/atlassian-jira-enterprise-3.13.5-standalone/bin/startup.sh
21. I tailed the log file and it looked like a clean startup.
22. I browsed over to http://bugs.shore.mbari.org:8080 and got the start up page.
23. I clicked on the "Import existing data" link and specified the /data/backups/3.12/final-upgrade-2015-08-21/final-jira-migration-backup-2015-08-21.zip as the backup file and /data/jira3135/indexes as the index location
24. I tailed the log file during the import process and everything looked great ... YEEEEEEEEEEESSSSSSSSSSSSSS!!!!!!
25. OK, so far so good. Attachments were there and everything.
26. I then went to the administration panel and performed another backup to XML using the file nanme final-jira-migration-3135-backup-2015-08-21 and selected the zip option.
27. It created the zip file in the JIRA tomcat bin directory! So I moved it to /data/backups/3.13.15/final-upgrade-2015-08-21
28. I created a tar of the attachments (which was in the /data/jira_3_12 directory) and moved it to /data/backups/3.13.15/final-upgrade-2015-08-21 also
29. I then shutdown the 3.13.5 JIRA instance for the LAST (hopefully) time!!
30. I fired up Aqua Data Studio again and deleted all the stuff in the Jira4 database on solstice 2
31. I then cd'd to /opt/jira4/logs and cleaned out any log files
32. I cd'd to /opt/jira4/work and removed the .pid file and the Catalina directory
33. I cd'd to the /opt/jira4 directory and removed the temp directory too.
34. I then cd'd to the /data/jira445 directory and removed everything but the dbconfig.xml file
35. I then started JIRA 4 and tailed the log file
36. It created all the tables in the DB as well as all the directories fine.
37. I copied the /data/backups/3.13.5/final-upgrade-2015-08-21/final-jira-migration-3135-backup-2015-08-21.zip to the /data/jira445/import directory
38. I copied the /data/backups/3.13.5/final-upgrade-2015-08-21/final-jira-migration-3135-attachments.tar to the /data/jira445/data directory
39. I untarred it there and it put all the attachments in the attachments directory.
40. I then removed the tar file.
41. I then went to the http://bugs.shore.mbari.org:8180 url in my browser
42. I clicked on the "Import your existing data" link
43. I entered /data/jira445/import/final-jira-migration-3135-backup-2015-08-21.zip in the File name box and then clicked import.
44. It bounced back because of eval license was needed, so I clicked on the generate eval license and agreed to the terms, Yes to install license and then clicked import.
45. I tailed the log file and everything worked!!!! Attachments too!!!!
46. I logged in and went to the admin panel.
47. I went to the Import and Export and clicked on Backup System tab on the left.
48. I entered the file name final-migration-445-2015-08-21 and clicked Backup
49. This created the backup located here: /data/jira445/export/final-migration-445-2015-08-21.zip
50. I then shutdown the JIRA4 for the (hopefully) LAST TIME!!!!
51. I created the /data/backups/4.4.5/final-upgrade-2015-08-21 directory
52. I then moved the /data/jira445/export/final-migration-445-2015-08-21.zip to the /data/backups/4.4.5/final-upgrade-2015-08-21 directory
53. I cd'd to the /data/jira445/data directory and tarred up the attachements directory to the final-migration-445-attachments-2015-08-21.tar file
54. I then moved that file to the /data/backups/4.4.5/final-upgrade-2015-08-21 directory
55. I cd'd to the /opt/jira5/logs directory and removed all the log files
56. I cd'd to the /opt/jira5/work directory and removed the Catalina directory and the pid file
57. I cd'd to the /data/jira5211 directory and I removed all the directories except for the dbconfig.xml file
58. I used Aqua data studio to delete all the tables in the Jira5 database (this took a couple of rounds of delete due to key constraints)
59. I then started JIRA 5 using /opt/jira5/bin/start-jira.sh and the DB tables and /data/jira5211 directories were all created OK
60. I copied the /data/backups/4.4.5/final-upgrade-2015-08-21/final-migration-445-attachments-2015-08-21.tar to the /data/jira5211/data directory
61. I then untarred the file there which put all the attachments in the attachments folder.
62. I then copied the /data/backups/4.5.5/final-upgrade-2015-08-21/final-migration-445-2015-08-21.zip to the /data/jira5211/import directory
63. I tailed the /opt/jira5/log/catalina.out file and opened http://bugs.shore.mbari.org:8280 in my browser
64. I clicked on the "import data" link
65. I put /data/jira5211/import/final-migration-445-2015-08-21.zip in the file name field and then clicked on Generate an evaluation key
66. I filled out everything and it put the license key in and then I clicked on "import"
67. Everything seemed to go smoothly, so I logged in and then created a backup by going to Administration->System->Import and Export.
68. I input the file name final-upgrade-5211-2015-08-21 which created the /data/jira5211/export/final-upgrade-5211-2015-08-21.zip file
69. I shutdown JIRA 5 for (hopefully!) the LAST TIME !!!
70. I tarred up that /data/jira5211/data/attachments directory and moved it to /data/backups/5.2.11/final-upgrade-5211-2015-08-21/final-upgrade-5211-attachments-2015-08-21.tar
71. I moved the backup that was in the /data/jira5211/export directory to the /data/backups/5.2.11/final-upgrade-5211-2015-08-21 directory
72. Using Aqua data studio, I deleted everything in the Jira6 database (took a couple rounds due to keys)
73. I cd'd to /opt/jira6/logs and removed all the log files
74. I cd'd to /opt/jira6/work and deleted everything there
75. I cd'd to /data/jira649 and removed everything but the dbconfig.xml file
76. I then cd'd to /opt/jira6/bin and started jira using jira-start.sh
77. I tailed to log file to make sure it all started up OK.
78. After successful start up, I copied the /data/backups/5.2.11/final-upgrade-5211-2015-08-21/final-upgrade-5211-2015-08-21.zip file to the /data/jira649/import directory
79. I copied the /data/backups/5.2.11/final-upgrade-5211-2015-08-21/final-upgrade-5211-attachments-2015-08-21.tar to the /data/jira649/data directory and untarred it which put all the attachments in the attachments directory.
80. I then went to http://bugs.shore.mbari.org:8380 to kick off the set up
81. I tailed the log file in the terminal to make sure all was OK
82. I clicked on "import your data" link
83. I put /data/jira649/import/final-upgrade-5211-2015-08-21.zip in the file name box and clicked on Generate evaluation license, followed the instructions and then clicked on Import
84. Everything seems to have worked (including attachments)!!!
85. I went to User Management->User Directories and I moved the JIRA internal directory up in the order of directories and disabled the Remote Crowd Directory
86. I then did an export using System->Backup System and used the file name final-upgrade-6211-2015-08-21
87. I then shutdown the JIRA 6 for (hopefully!!!) the LAST TIME !!!!
88. I cd'd to the /data/jira629/data directory and created the final-upgrade-629-attachments-2015-08-21.tar file of the attachments directory
89. I cd'd to the /data/backup/6.4.9/ directory and created the final-upgrade-649-2015-08-21 directory.
90. I cd'd to that directory and moved the backup file and the attachment tar to that directory.
91. I then opened a terminal on my local machine and SCP'd those backup files locally.
92. I then mounted the WebDAV directory on my local machine using finder an connecting using https://mbari1.atlassian.net/webdav/
93. I then copied the backup files I scp'd to may local machine to the remote WebDAV directory.
94. I logged in to our cloud system and went to Administration->System
95. I clicked on JIRA Import on the left hand side
96. I only selected the XML backup zip to import as Atlassian has to do the attachments.
97. I gave me the option of updating URLs that were in issues, I selected the ones point to oceana and continued.
98. It warned me that everything would be replaced. I left the email enabled and continued.
99. It looks like it did a purge first, then the import.
100. It failed and I updated my support ticket to have them look at it
101. They uploaded and re-indexed and it wiped out all accounts, so I logged in as admin/admin and it put me through a setup routine
102. I changed that admin password, but it looks like it is a limited 'admin'. I am wondering if the account needs to have site admin because I can't get into any of the user management stuff.
103. That was it, Atlassian made the admin account a part of the site-admins group and I am golden.
104. I went through and de-activately almost all the accounts except for the ones I knew about and reset all their password to a default that I will email them directly so they can login and change it.
105. I added the MBARI Logo
106. I enabled Gravatar images

WHEW, TIME FOR A BEER!